1. Field of Invention
The present invention relates to telecommunications call processing. More specifically, it relates to processing of a vanity telephone number dialed by a caller with a conventional telephone, so as to access a national virtual telephone number database to provide benefits, such as improved connection efficiency, selected services or products, to the caller, the servicing location(s) associated with the vanity number dialed and/or the vanity number advertiser.
2. Description of the Related Technology
Traditionally, entities with multiple employees, departments and/or locations, such as businesses and government agencies, have provided their customers with multiple telephone number points of contact, with usually at least one telephone number for each employee, department and location. This has placed a major burden on customers and prospective customers to find, remember, dial and be connected to the correct intra-entity telephone number for the services desired. It also has created cost and administrative burdens on these entities to publish and advertise multiple telephone numbers.
In the new world of electronic commerce, many such entities have started advertising xe2x80x9cone numberxe2x80x9d, vanity telephone numbers as their primary customer contact point. These vanity numbers are usually national 10 digit numbers starting with area codes such as xe2x80x9c800,xe2x80x9d xe2x80x9c888,xe2x80x9d or xe2x80x9c900xe2x80x9d, local 7 digit numbers starting with an exchange such as xe2x80x9c555xe2x80x9d and xe2x80x9c950xe2x80x9d or special purpose three digit numbers like xe2x80x9c311,xe2x80x9d xe2x80x9c411xe2x80x9d or xe2x80x9c911xe2x80x9d. These numbers are usually easy to remember, such as 1-800-FLORIST. Unlike regular telephone calls with only two participants, vanity telephone number calls can have three participants, recipients, or beneficiaries:
1. The Vanity Number Advertiser
2. The Caller or Consumer
3. The Servicing Location(s)
Based on the increased volume of calls to these vanity numbers and customer demands for 24 hour support during seven days a week, reduced telephone busy signals and shorter hold times, vanity number advertisers have begun answering these calls with a new technology called Voice Response Units (VRU), also known as Interactive Voice Response (IVR).
Currently, there are over 50 manufacturers of VRUs. The commercialization of the VRU and changes in advertising practices has also spawned large numbers of new VRU applications from product manufacturers. Products may be advertised by an infomercial showing an xe2x80x9c800xe2x80x9d number to call so that a consumer may obtain a list of nearby dealers and/or a product brochure. The 800 number is answered by a VRU which requests the caller to record their name and address. This partially automates the call process, but requires large amounts of disk storage to store the caller provided recorded voice information and creates a large amount of post call work for the advertiser. For example, the advertiser must listen to, understand, transcribe the caller""s name and address, certify the address by use of a United States Postal Service (USPS) coding accuracy support system (CASS), manually compile a list of nearby dealers and mail the information packet to the caller""s address. These inefficiencies have created a need to further automate VRU applications. This is accomplished through what is now called intelligent call processing technology.
In this context, automated intelligent call processing (ICP) is defined as the capture of network provided data, such as automatic number identification (ANI) and dialed number identification service (DNIS), and caller-provided data, such as data entered by Dual Tone Multi-Frequency (DTMF) through a Touchtone telephone key pad or the caller speaking through the telephone to a VRU. ICP also involves the VRU accessing external databases that can decipher, validate, process and fulfill the caller""s request by playing pre-recorded messages, creating call specific messages and speaking them to the caller, storing call captured information that can be accessed by or forwarded to the caller, servicing location or vanity advertiser, and/or automatically routing and connecting the caller to the servicing location or department. Semi-automated intelligent call processing is characterized by automating components of the call through intelligent call processing, but having some portion of the request still requiring live operator support during the call.
There are three primary components to an intelligent call processing system:
the network: the system level hardware and software that provides the platform for intra- and inter-system and participant communications;
the information retrieval, processing and storage: the databases and processing algorithms that provide the network application with the information required to fulfill the request; and
the applications: the processes that process and fulfill the request(s) of the caller, the servicing location and/or the vanity advertiser by utilizing the network and the retrieved, processed and stored information.
The Network
The VRU is the device that can be used to replace the network operator and/or the answering party. Early primitive, non-integrated ancestors to the VRU are the caller ID box and the answering machine. Current state-of-the-art VRUs are programmable devices that not only capture and process network provided data but also accurately translate caller spoken numbers and words into textual or binary data, and convert digital text in the form of words and sentences into speech that is understandable by most callers. The VRU capabilities in these areas are continuing to rapidly improve. The last remaining obstacle to VRU automation is immediate access to more information. This required better network access to network and remote databases and a way to associate the digital data stored in these databases with network provided data, such as ANI and DNIS, and caller provided telephone input in the form of sound: voice or DTMF accurately translated into digital data.
The computer network portion of this problem has been addressed with faster 32 bit and 64 bit processors, vast amounts of cheap RAM and disk storage, new levels of Computer Telephone Integration (CTI) and advances in computer wide area networking that provides real time access to many different databases stored on different computer systems physically located in different parts of the country. This is demonstrated in part by a variety of consumer computer-interface applications supported by computer network services, such as CompuServe(copyright), America Online(copyright), Microsoft Network(trademark) and the Internet.
There are nearly 200 million access points in the national telephone network, which is many times the current number of access points for all of the computer networks combined. The major limitation of the telecommunications voice network is that other than the limited amount of network provided data and voice, the only widely supported communications means is another form of sound, i.e., DTMF, which is a very primitive way of achieving one-way communication. Voice recognition has improved tremendously over the last few years, but is still a long way from being able to translate the words spoken by millions of people with different voices and accents into digital text words with 100% accuracy.
A few access points have videophones that support both sound and video in both send and receive modes. The technology has been around for many years to convert digital text data into video, and digital raster data in the form of maps and pictures into video, and transmit it over the national telecommunications network. There is also primitive technology available to scan and translate video images in the form of hand-written messages and typed characters, words and sentences into digital data, such as the ASCII character set. Today, none of the VRU manufacturers provide either of these capabilities with their current products. As videophones become more common in use, the existing technology to translate digital data into the form of a video image and transmit it to the caller will likely become a standard feature in all next generation VRUs.
A few access points also have computers with modems, speakers, microphones and telephone emulation software, such as Microsoft Phone. There is potential to have the computer translate on-screen typed text into DTMF tones using a more robust DTMF coding scheme and to have this translated back into digital text at the VRU. However, current VRUs do not have this capability.
Information Retrieval, Processing and Storage
Currently, VRUs have no caller-friendly capability to accurately translate caller voice or DTMF input into complex digital database access keys. Consequently, VRU database access has been limited to databases indexed by a simple numeric key. These include pre-recorded messages and internal client customer databases indexed by customer ID. The ID is usually in the form of a telephone number, account number, policy number, order number or other numeric data that is provided by the network, can be entered by DTMF, or accurately translated into digital data by a VRU using current voice recognition technology. This method works for applications with existing customers who know their customer ID. However, for new customers, new businesses or new applications that service different target markets, these internal databases are either too sparse in coverage or do not contain the required information.
On the other hand, there are many frequently updated national databases that have not been accessible by VRUs using network provided data or caller provided telephone input. These include:
The USPS address coding guide.
The US Census Bureau""s TIGER (Topographical Integrated Geographic Encoded Record) and 1990 census data files.
Geographic and spatial files from Geographic Data Technology, Inc. (GDT) and ETAK(copyright), such as ZIP+4 to latitude and longitude, ZIP+4 to census block, ZIP Code and census boundary, and enhanced TIGER files.
Household and individual databases from Polk, First Data Resources (FDR), Metromail and the big three credit bureaus: Equifax, Trans Union and TRW.
Property databases from TransAmerica, TRW Ready Data and ACXIOM DATAQUICK.
Updated census data files and geodemographic databases from Claritas, Equifax National Decision Systems, Urban Decision Systems (UDS), CACI and Strategic Mapping, Inc. (SMI).
Business and government location databases from American Business Information(copyright) (ABI), DUNS, ProCD and Database American.
Business financial databases from DUNS and TRW.
Hundreds of private company, state and local government and regional files of various types.
All the above databases have one or more of the following limitations that has previously restricted them from being used in VRU applications:
They do not contain a telephone number field.
They contain a telephone number field but a high percentage of records have missing telephone numbers, have out of date telephone numbers or have a very limited amount of data associated with the telephone number.
They do not share a common access key that the caller knows, is willing to provide and can easily communicate to a VRU.
The missing link in making all the above data available in real-time to VRU applications is creating a standardized, precise and universal database linkage key that can be assigned to all the United States telephone numbers and all of the above mentioned databases. This key needs to act as a direct and/or translator linkage mechanism between the telephone number and databases for spatial, geographic, USPS address, household, individual, business location, government location, business financial, property and client service locations with service areas of any defined geographic size and shape. Since the most common trait shared among the above mentioned databases is their geographic/spatial location, definition and/or relationship, the most logical solution would be a universal hierarchical geographic/spatial linkage key, xe2x80x9cSpatial Keyxe2x80x9d. Utilizing the Spatial Key to create a virtual telephone number database would make it practical to automate many VRU applications that provide the caller with information, connect the caller with a servicing location and/or capture or retrieve caller related information to assist the vanity advertiser and/or the servicing location in providing better during call and post-call service to the caller.
Applicant is not aware of any product or method that uses a single key to create a virtual telephone number database by linking to many different and seemingly unrelated databases for supporting multiple applications. Savage et al. (U.S. Pat. No. 4,954,958) associates the 10-digit telephone number with an address-indexed street network database to provide directions over a telecommunications network to a caller. Savage uses two 10 digit telephone numbers input by the caller to provide directions from point A corresponding to the location of the first telephone number to point B corresponding to the location of the second telephone number.
As a telephone number to address translation mechanism, the Savage system uses the American Business List (ABL) file which is compiled from the national yellow pages. The ABL file contains approximately 10 million unique business telephone numbers and was originally created for use as a direct marketing database and a national business directory assistance database. The Savage system indexes each 10-digit telephone number into the ABL File to retrieve a business name and a raw address for each end point. In the telecommunications and direct marketing industries, this well-known process of starting with a phone number and looking up a name and address from a directory database is called a reverse directory search. The Savage system uses the raw addresses retrieved by this process as a linkage mechanism to what is referred to as a geodata digitized mapping database from MapInfo(copyright). The source of the MapInfo database most likely is the Census Bureau Geographic Base File-Dual Independent Measurement Encoded (GBF-DIME), which is the predecessor to the TIGER files.
There are many technical issues associated with using a raw, non-standardized and free-formatted address which is composed of a street number, street pre-direction, street name, street type, street post-direction, city name and state as a linkage means between two databases compiled from different sources. These issues include: field size, address formatting and parsing, upper case and lower case, abbreviations, alternate names, alternate spellings (First vs. 1st), missing components and the source of city name. For example, Highway 101, PC HWY, PCH, Pacific Coast Hwy, First Street and 1st St. are all valid alternate street names and types for 1st St. in Encinitas, Calif. This large number of address permutations requires very sophisticated address parsing, standardizing, sorting, matching and scoring algorithms to correctly match raw addresses from two independent databases.
The Savage system does not address the above issues in matching the two raw ABL retrieved addresses to their corresponding two raw addresses on the preferred MapInfo digitized mapping database. The Savage description of the address matching embodiment is: xe2x80x9cthe central processor will retrieve from the geodata digitized mapping database the routing data correlated to the geographic location addressesxe2x80x9d. What is needed is a simple, accurate and definable way (such as a Spatial Key) to precisely hierarchically code the address associated with a telephone number and use it as a hierarchical match key to retrieve matching data from other databases coded with all or part of the same hierarchical match key.
In addition, the Savage system does not provide any automated means to determine a servicing location nearby the caller. The caller must know and input the telephone number of the desired service location to get directions. This also eliminates the possibility of providing directions to service locations, such as drop boxes and automatic teller machines (ATMs) that do not have telephones.
Riskin (U.S. Pat. No. 4,757,267) uses the first six digits of the caller""s telephone number to select a nearby serving location by performing an on-the-fly calculation to determine the nearness relationship. However, none of the databases mentioned above are accessible by Riskin""s process because the first six digits of the telephone number do not provide enough precision to identify the housing or business unit location of the caller.
There are also two previous systems that use a client-specific Caller Telephone Number To a Service Location Telephone Number table as a means of connecting a caller to a servicing location. Cotter (U.S. Pat. No. 4,797,818) describes a manually intensive process for building and maintaining this table. Wegrzynowicz (U.S. Pat. No. 5,136,636) only references the table as a system component that is built and maintained by the client, but does not describe how the client performs this function.
Neither Savage, Riskin, Cotter, nor Wegrzynowicz use a linkage process similar to the Spatial Key. Further, none of the prior systems mention using a single linkage mechanism as a means to link to multiple databases to support multiple applications.
Developing a Spatial Key
In developing a universal Spatial Key the following must be considered:
1. The stability and updateability of the key over time.
2. The ability of the key to be a unique housing, business and/or postal delivery unit identifier.
3. The geographic hierarchy and precision of the key.
4. The number and quality of updated commercial and public translation tables to and from the key.
5. The availability of tools for third parties to place the key on their files.
6. The ability to precisely associate the key to service locations with service areas of any geographic defined size and shape.
7. The ability of regulated telecommunications entities to code their files with the key and to pass the key outside the regulated portion of the network.
Based on the above considerations, there are four primary candidates for the key:
Most recent census block code
Latitude and Longitude
Telephone Number
USPS ZIP Code
The other candidates, such as a voting precinct, are eliminated from discussion because of a lack of precision.
Most Recent Census Block Code
The Census block code is a hierarchical 15-digit Federal Information Processing Standard (FIPS) number that is updated once every 10 years in conjunction with the United States decennial census. It has the following seven level hierarchy:
2 digit state code
3 digit county code
4 digit tract code
2 digit tract suffix
1 digit block group code
2 digit block code
1 character block part code
The critical limitation of using census block as the Spatial Key is it is not precise enough to act as a unique housing or business unit identifier.
Latitude and Longitude
Latitude and longitude are used in a spherical coordinate system to identify a point on the earth. Its stability in the United States is a function of the North American Datum (NAD) which was originally established by the United States Geological Survey (USGS) in 1927 and was updated in 1983. To use the latitude and longitude as a hierarchical key, the base 10 or binary digits of the latitude and longitude pair must be interleaved to form a single number. The result of this interleaving is generally referred to as a quadtree. Alternatively, the latitude and longitude pair may be combined and/or translated to form another identifier. When latitude and longitude are stored in millionths of degrees, the interleaving creates a nine level base 10 and a sixteen level binary hierarchical system with a mathematical precision of approximately plus or minus 4 inches.
This level of precision is supported by the US Department of Defense""s implementation of Global Positioning Satellites (GPS) technology. However, the two primary commercial means by which latitudes and longitudes are assigned to a location, i.e., the TIGER files (NAD27) and commercial level GPS (NAD83), do not support this level of precision. For locations in California, the latitude and longitude coordinates vary by as much as 300 feet between NAD27 and NAD83. There is a mathematical relationship between NAD27 and NAD83, such that latitudes and longitudes can be converted back and forth.
In addition to the above precision issues, latitude and longitude would not make a good choice for a unique housing or business identifier because multi-story buildings require a third coordinate, i.e., elevation. Another limitation with latitude and longitude as a Spatial Key is it requires very specialized Geographic Information System (GIS) databases and knowledge to Spatial Key code. However, commercial level latitude and longitude has no equal when input into a GIS system using data from a single NAD that is indexed by quadtree in showing a relative location on a map with precision in the 30 to 100 foot range.
Telephone Number
The 10 digit telephone number appears to comprise a three level hierarchical system.
3 digit Numbering Plan Area (NPA) or area code
3 digit NXX, exchange or prefix
4 digit line number or suffix
Currently, NPAs do not spatially overlap and, with two minor exceptions, do not cross state boundaries. However, there are current plans to create spatially overlapping NPAs in the future. This will require callers in these NPAs to always dial 10 digits. The next non-spatially overlapping level is not the NXX, but the central office (CO) or wire center (WC). Each CO supports one to a few NXXs. Usually over time, the line numbers associated with a NXX become randomly distributed across the locations of the households and businesses serviced by the CO. There are also NXXs, such as 555, 950 and those assigned to cellular phones and pagers, that have no specific geographic boundaries within the NPA. There are also non-spatial NPAs such as 800, 888 and 900. These above items could cause difficulties in an intelligent call processing system if the telephone number was used as the Spatial Key.
There are several additional deficiencies in using the telephone number as the Spatial Key. These include, for example, the situation of using the telephone number as a unique housing or business unit ID. However, there would be multiple IDs for housing units and businesses with multiple telephone numbers. This would lead to excessive complexity in the system due to the multiple IDs. The main negatives associated with using the telephone number as the Spatial Key are the difficulty of accurately coding other databases with a telephone number and the regulatory issues related to transporting telephone numbers obtained from regulated sources outside the regulated telecommunications network.
USPS ZIP Code
The ZIP Code at the 11 digit level is called the Delivery Point Code (DPC) or ZIP+6 and uniquely identifies an individual building, such as 123 N Main St. The DPC is the most precise geographic code presently supported by the USPS and can be used as a unique housing or business unit identifier for single unit structures. However, it cannot uniquely identify a housing or business unit in multiple unit buildings or firms.
The DPC is a geographic hierarchical numbering system of five levels defined as follows:
3 digit ZIP Code is called a Sectional Center.
5 digit ZIP Code is called a Post Office Service Area with a preferred USPS name called the last line name. This is the name shown on the last line of a mailing address. There are 3 special types of ZIP Codes. Two of these, xe2x80x9cFleet Post Office (FPO)/Armed Forces Post Office (APO)xe2x80x9d and xe2x80x9cPO Box onlyxe2x80x9d, do not have precise spatial definitions, but can be linked to unique household equivalent mailing addresses.
7 digit ZIP Code identifies a geographic sector within a Post Office Service Area.
9 digit ZIP Code is called a ZIP+4 and is usually the geographic area of one side of a street within a single one hundred address range block. It is a unique household level identifier for most USPS"" PO Box and RR addresses which usually do not have precise spatial definitions.
11 digit ZIP Code is called the Delivery Point Code or ZIP+6 and uniquely identifies a street number address, such as 123 N Main St. The street address is the most common USPS address and is a unique housing or business unit identifier for all single unit buildings with unique street addresses.
Applications
Historically, many high-demand telephone call processing applications have not been commercialized because of one or more technical or economic issues including: automated caller interface technology, integrating telephone and computer networks, and telephone number database validation, coverage, depth and linkages.
In addition, when the above issues are addressed, all known previous efforts in the technology have focused on a custom solution to a specific application, and not on an integrated system solution that meets multiple application needs and the needs of the caller, servicing location and/or vanity number advertiser.
Automated Applications
The following is a partial list of automated application examples that have not either been addressed by previous art or addressed with a highly customized individual solution. It would be desired for all these applications to be automated using a common architecture in which the caller dials a vanity number and the system captures the caller""s 10 digit ANI and DNIS. The architecture would only require the caller to respond to application dependent system voice prompts and/or only input a telephone number, if a telephone number different from the ANI is required by the application.
Connecting a caller to a servicing location: The prior technology does not support service locations having service areas of any size and shape, nor situations where geographic precision is required. A solution is desired that provides these abilities in an integrated common architecture.
USPS address retrieval: This is presently addressed by having the caller record their name and address, which is later listened to by a person and transcribed. The transcribed address is then processed through CASS certified software for use in an existing customer database of addresses indexed by telephone number. What is desired is a way to use a caller provided telephone number to directly retrieve the CASS certified USPS address associated with the caller provided telephone number and, in applications requiring 100% accuracy, providing the caller a means to verify the retrieved address. In addition, in a post call process, the retrieved, verified and stored address and additional linked data is desired to be used by the vanity advertiser to mail to the caller, for example, a requested store coupon, menu, catalog or informational packet.
The VRU speaks the service location(s) name, address and/or micro directions (to the caller): Service location information is needed by the caller to mail, pickup and/or drop off something to a selected servicing location. The greatest need for micro-area directions to service location(s) is with service locations very small in size, such as Federal Express, UPS and USPS drop boxes, or ATMs located in large physical entities, such as shopping centers or multi-story buildings. A solution is desired that provides these abilities in an integrated common architecture.
The VRU speaks driveable street directions from the caller""s location to the selected service location (to the caller). In addition, in a call parallel application, after transferring the call to the servicing location, the application retrieves the service location""s FAX number from a Service Location Table and faxes to the service location the caller""s telephone number, address and a map and/or directions from the service location to the caller location to assist the servicing location with delivery to caller. The Savage reference describes a application that requires the caller to input two telephone numbers, and the only benefactor to the Savage device is the caller. What is desired is a system that does not require the input of any telephone numbers, or at worst, only one telephone number is provided by the caller. In addition, services would be provided to the caller, servicing location and/or the vanity advertiser.
Eliminating servicing locations based on days and hours of operation and/or services offered: A solution is desired that provides these abilities in an integrated common architecture.
Caller profiling based on Census or geodemographic data: A system is desired, based on a caller""s geodemographic code and product consumption rates, to only present product options to the caller that the caller is most likely to buy, or to route the call to an appropriate sales specialist based on the caller""s profile.
Applications that require the caller""s name and/or individual data such as product registration and insurance, loan or credit applications: What is desired is a way of linking a Spatial Key to a household database containing data, such as name of head of household, street address, number of children in the household and the names of other individuals living in or associated with the household. The system would speak these individual names and the caller would identify himself or herself. Then the system would link to individual data, such as date of birth, credit rating, and so forth, and provide it to the caller, servicing location, and/or vanity advertiser.
Business Location Data Retrieval: What is desired is a way of linking the caller""s Spatial Key to a business database containing data, such as name of Business, SIC, Number of employees and DUNS number, which would link directly into the DUNS database for credit information.
Real Property Database Retrieval: What is desired is a way for a contractor, for example, before bidding on a job, to dial a vanity number that interfaces with an automated property database, enter the telephone number of the supposed residential property owner and verify the ownership, address, mortgage holder, and any outstanding liens on the property.
Semi Automated Applications
There are telephone call processing applications where operator decisions and/or assistance are required that can also benefit from a virtual telephone number database. The following are desired exemplary applications:
Address Lookup and verification by an operator taking a telephone order: In current telephone order systems, an operator key enters a customer""s address and verifies the spelling with the caller. What is desired is a way for the caller""s telephone number to be passed to the computer system to automatically retrieve the CASS certified address associated with the caller""s telephone number and display it on the operator""s visual display. The operator would then ask the caller for the address to which they want the order shipped. If the addresses match, the operator would not have to key enter it and verify the spelling with the caller. If the addresses are different, there is a high potential that the caller is trying to make a fraudulent order and the operator would ask additional questions required to make this determination.
Real Time Address to Spatial Key Coding and Spatial Key to Client Table with Off-Line Master Table update: What is desired is a way of continually updating a Master Table (Phone Number to Spatial Key table) that supports multiple clients and applications in the situation when a caller is trying to be connected to a servicing location and has provided a valid telephone number that is not in the Master Table.
xe2x80x9c911xe2x80x9d application: In a real time Public Health and Safety application, the caller places an emergency call to the emergency telephone number xe2x80x9c911.xe2x80x9d The xe2x80x9c911xe2x80x9d application costs the U.S. taxpayer several billion dollars each year, and is currently overloaded with non-emergency calls. What is needed is a more economical alternative system for non-emergency xe2x80x9c911xe2x80x9d calls that can alleviate the load from the current overworked system.
A system and method that uses a single Spatial Key to create a virtual telephone number database by linking a caller""s or caller provided telephone number to many different and seemingly unrelated databases for supporting multiple applications would be an advance in the industry. What is needed is an automated means to determine a servicing location nearby the caller, such that the caller does not need to know and input the telephone number of the desired service location to get directions or other desired information. This would facilitate providing directions to service locations, such as drop boxes and automatic teller machines (ATMs) that do not have telephones. Such a system would utilize all ten digits of the telephone number to provide enough precision to identify the housing or business unit location of the caller telephone number. What is desired is the integration of VRU technology with a CTI network and a virtual telephone number database to provides a way to support a host of applications that were not previously possible. Information benefits derived by the caller, the servicing location and the vanity advertiser would be made possible by retrieving information from a virtual telephone number database created through Spatial Key linkage technology. Thus, a single linkage mechanism as a way to link to multiple databases to support multiple applications is needed. A solution is desired that provides these abilities in an integrated common architecture.
The call processing applications examples illustrated above and additional similar applications are satisfied by the present invention that includes a telephone call processing system and method in a CTI network. The present invention also includes a process for building and maintaining a Master Telephone Number to Spatial Key Table for use in a CTI network. A significant factor in this invention is the selection of a Spatial Key type. Several candidates including the Most Recent Census Block Code, Latitude and Longitude, Telephone Number, and USPS ZIP Code may be considered. Each Spatial Key type candidate has strengths and weaknesses. The extended ZIP code has been selected as the preferred embodiment for use in this invention as described below.
Selecting a Spatial Keyxe2x80x94Extended Zip Code
The Delivery Point Code (DPC) or ZIP+6 is the most precise geographic code presently supported by the USPS and can be used as a unique housing or business unit identifier for single unit structures. However, it cannot uniquely identify a housing or business unit in multiple unit buildings or firms. To solve this problem, it is necessary to further subdivide the DPC using the USPS secondary address, such as apartment 2B, to create a unique housing or business unit identifier. The USPS secondary address is stored as an eight character field called the secondary address field in the USPS Address Management System (AMS) II ZIP+4 address coding guide. Appending the secondary address to the end of the DPC results in an extended 19 digit USPS ZIP Code, thereby creating a unique housing unit or business unit identifier.
The extended 19 digit ZIP Code is a six level hierarchical geographic numbering system that uniquely identifies every housing, business and postal delivery unit serviced by the USPS. It is a geographical hierarchical numbering system, because each of the six levels defines a smaller geographic area totally enclosed within the next higher level. Definitions of the first five levels are provided in the Background section. A description of the sixth level is as follows:
19 digit ZIP Code is required to create a unique housing or business unit identifier for multiple unit buildings or equivalents, such as trailer parks or firms receiving large volumes of mail.
The benefits to using the 19 digit ZIP Code as the Spatial Key are:
1. The USPS provides monthly updates to all postal files.
2. The ZIP Code has 6 hierarchical levels.
3. There are very economically priced commercial tools, such as Group 1 and Mailer""s Software, that address standardize and assign 11 digit ZIP Codes to files containing raw addresses.
4. Adding the remaining 8 digit code is a fairly basic process for records that require a secondary address to create a unique housing or business unit identifier.
5. There are frequently updated ZIP+4 to latitude and longitude and ZIP+4 to census block translation tables available from the USPS, GDT, Business Location Research (BLR), ETAC and others.
6. There are no technical barriers to creating a DPC to latitude and longitude file if one was required. This would provide the most precise, theatrically possible latitude and longitude assignment of street addresses.
7. There are no restrictions on passing an extended USPS 19 digit ZIP Code outside the regulated telecommunications network because it is not considered customer provided network information.
8. There is a major public safety initiative to change as many RR Box number addresses to street addresses as possible, thus increasing the coverage of the Spatial Keys that can be linked to a precise latitude and longitude.
Although the extended 19 digit ZIP Code is not a perfect universal Spatial Key, it is far superior to the other alternatives for most applications. There are obviously some specific applications where one of the other Spatial Key alternatives could be used. If at some point in the future, the USPS decides to revise the hierarchical numbering system for the ZIP Code, the new ZIP system would most likely then be the preferred choice for a Spatial Key.
Applications
The integration of VRU technology with a CTI network and a virtual telephone number database provides a means to support a host of applications that were not previously possible. The partial list of automated and semi-automated examples below is intended to show the overall scope of the benefits derived by the caller, the servicing location and the vanity advertiser made possible by retrieving information from a virtual telephone number database created through Spatial Key linkage.
Automated Applications
The following is a list of exemplary automated applications that utilize the virtual telephone number database created by the Spatial Key linkage technology.
1. Connecting a caller to a servicing location: This application connects the caller directly to a servicing location retrieved from a Spatial Key indexed Client Table based on the caller provided telephone number being physically located inside the retrieved servicing location""s exclusive service area geographically defined as any size or shape. High geographic precision of the location is supported. In cases where the caller provided telephone number is located inside multiple non-exclusive service areas, this application provides the caller a VRU menu of retrieved servicing locations names and then directly connects the caller to the closest servicing location or the one selected by the caller. These abilities and features are provided in a integrated common architecture.
2. USPS address retrieval: This application is based on utilizing the caller or caller provided telephone number to retrieve the callers CASS certified USPS address. The caller""s Spatial Key is linked to the Spatial Key coded and indexed USPS address coding guide and the address is retrieved. The VRU speaks the address back to the caller for confirmation in applications requiring 100% accuracy before linking to any other databases. In addition, in a post call process, the retrieved, verified and stored address and additional linked data can be used by the vanity advertiser to mail to the caller, for example, a requested store coupon, menu, catalog or informational packet.
3. The VRU speaks the service location(s) name, address and/or micro directions (to the caller): Based on a caller provided telephone number, the caller""s Spatial Key is used to retrieve location ID(s) of the service location(s) nearest the caller from a Client Table that is associated with the caller""s DNIS. The retrieved ID(s) are indexed into the corresponding Service Location table to retrieve the above mentioned information. This can be used by the caller to mail, pickup and/or drop off something to the selected servicing location. Providing the caller with pre-stored micro area directions to the service location(s) is usually used with service locations very small in size, such as Federal Express, UPS and USPS drop boxes, or ATMs located in large physical entities, such as shopping centers or multi-story buildings. These abilities and features are provided in a integrated common architecture.
4. The VRU speaks driveable street directions from the caller""s location to the selected service location (to the caller): The caller""s Spatial Key is linked to a latitude and longitude which is then fed into a GIS server accessing a latitude and longitude coded and indexed street network database. The database provides a set of directions that are spoken by the VRU. The caller does not need to enter either the source (under normal circumstances) or destination location telephone numbers. In a call parallel application: after transferring the call to the servicing location, the application retrieves the service location""s FAX number from a Service Location Table and faxes to the service location the caller""s telephone number, address and a map and/or directions from the service location to the caller location to assist the servicing location with delivery to caller. In this case, the GIS server returns the direction data in the form of a map and/or directions and passes this image to the FAX server.
5. Eliminating servicing locations based on days and hours of operation and/or services offered: In the case of multiple servicing locations, the final servicing location list is determined by comparing the days and hours of operation of each service location retrieved from the Service Location table with the day and time of the call. Another method involves having the caller select a pickup or delivery option, (for pizza, for example) and eliminating servicing locations from the list that are not currently open or do not offer the desired service. These abilities and features are provided in a integrated common architecture.
6. Caller profiling based on Census or geodemographic data: The caller provided telephone number is linked to a census block or block group database. The Census Block database contains demographic data, such as race, age, median household size and so forth, or a single numeric geodemographic code that is a composite of the census information which links into a geodemographic code by a product consumption table. Based on the caller""s geodemographic code and its product consumption rates, the VRU only presents product options to the caller that the caller is most likely to buy. There are also geodemographic systems that use the ZIP+4 as the base geography instead of the census block.
7. Applications that require the caller""s name and/or individual data such as product registration and insurance, loan or credit applications: The caller provided telephone number is linked to a household database containing data, such as name of head of household, street address, number of children in the household and the names of other individuals living in or associated with the household. The VRU can speak these individual names and the caller can identify himself or herself. After the step of identification by name, individual IDs associated with the selected name and stored in the database, such as social security number, state drivers license number, credit card number(s) and bank account number(s), can then be used as a linkage to link to individual ID-indexed databases containing individual data, such as date of birth, credit rating, and so forth. This information can then be provided to the caller, servicing location or vanity advertiser.
8. Business Location Data Retrieval: The caller provided telephone number is linked to a business database containing data, such as name of Business, SIC, Number of employees and DUNS number, which links directly into the DUNS database for credit information. The applications here are very similar to the applications for a household database.
9. Real Property Database Retrieval: Most real property databases are maintained by local government agencies and the data stored in these databases is considered public information. This data is compiled from the public agencies by companies, such as ACXIOM DATAQUICK, and made available to paying clients. Before bidding on a job, for example, a contractor could dial a vanity number that interfaces with an automated property database, enter the telephone number of the supposed residential property owner and verify the ownership, address, mortgage holder and if there are any outstanding liens on the property.
Semi Automated Applications
There are telephone call processing applications where operator decisions and/or assistance are required that can also benefit from a virtual telephone number database. The following are examples:
1. Address Lookup and verification by an operator taking a telephone order: The caller""s ANI is passed to the computer system via Integrated Services Digital Network (ISDN) to which the operator""s CRT is connected or the operator asks the caller for the telephone number and key enters it. The host computer passes the caller""s telephone number over the computer network to the computer storing the Master Table of telephone numbers with corresponding Spatial Keys and the Spatial Key coded USPS National Address database and requests the address associated with the caller""s telephone number. This CASS certified address is returned and displayed on the operator""s CRT. The operator then asks the caller for the address to which they want the order shipped. If the addresses match, the operator does not have to key enter it and verify the spelling with the caller. This saves both time and money and reduces mistakes. If the addresses are different, there is a high potential that the caller is trying to make a fraudulent order and the operator would ask additional questions required to make this determination.
2. Real Time Address to Spatial Key Coding and Spatial Key to Client Table with Off-Line Master Table update: A caller is trying to be connected to a servicing location and has provided a valid telephone number that is not in the Master Table. The call is transferred to an exceptions handling operator and the telephone number and DNIS are passed via ISDN to the operator""s host computer and displayed on the operator""s CRT. The operator asks for the caller""s address and key enters it. The operator then presses a function key that calls a program that USPS standardizes the address and assigns a Spatial Key. The operator validates the standardized address with the caller. If it validates, the operator then presses another function key that passes the Spatial Key and the DNIS to a program that brings up a list of servicing location(s) with their telephone numbers on the CRT screen. The operator then asks the caller which one they prefer and transfers the call by highlighting the selected service location and pressing another function key. The captured telephone number and Spatial Key are stored on disk or other mass storage and are retrieved later by another process that updates the Master Table which supports multiple clients and applications.
3. xe2x80x9c911xe2x80x9d application: In a real time Public Health and Safety applications, the caller places an emergency call to the emergency telephone number xe2x80x9c911.xe2x80x9d The caller""s telephone number is passed by Caller ID to the answering hardware which passes the information via ISDN to a Geographic Information System (GIS) computer with large CRT graphic terminals in front of dispatching operators. The system looks up the caller""s Spatial Key in a Master Table and then looks up the caller""s latitude and longitude in a Spatial Key to Latitude and Longitude table and the caller""s address from the Spatial Key coded and indexed USPS address coding guide. The caller""s location is then displayed in the map window on the answering dispatcher""s CRT along with the street network and the current location of all emergency vehicles by type and status. The caller""s address is displayed in the address window. Based on the type of emergency and the current location and status of the emergency vehicles, the dispatcher determines which vehicles(s) to dispatch and when they should be dispatched.
The call processing system includes means for receiving network provided call information or means for prompting and receiving optional caller provided input to capture a valid first location telephone number. The call processing system further includes a process for indexing the valid first location telephone number into at least one Master Telephone Number to Spatial Key database to retrieve information associated with the first location""s telephone number and a means to provide the received and retrieved information associated with the first location""s telephone number to provide one or more improvements to the service of at least one call recipient.
The improvements in service are provided to one or more of the following recipients: a caller, a servicing location and/or a vanity number advertiser. These improvements in service or benefits are provided either during the call, parallel to the call, and/or post call. The service benefits include the following: determining the selected servicing location telephone number and providing it to the network to automatically connect the caller to the selected servicing location; determining that the caller requires operator assistance and providing the network with the information required to connect the caller to a vanity advertiser operator; and/or providing one of a plurality of informational items.
The improvements in service illustrated in the application examples all relate to a consumer or business dialing a business or government vanity number. However, at some future point in time, the CTI network will evolve to where the called party can also be a consumer. At this future point in time, the called consumer can have access to all the information related to the calling telephone that the servicing locations and vanity advertisers have in the above examples, such as having the name, address, caller type (consumer, business, pay phone or government, etc.) associated with the calling telephone displayed on his or her future-generation caller ID box before he or she answers the telephone.
The preferred process uses the full 10 digits of the North American Dialing Plan 10 digit telephone number as the telephone number. Obviously, if the system were implemented within a single NPA with no overlapping NPAs, a 7 digit number could easily be substituted by one skilled in the art. Also, if at some point in the future, the North American dialing plan were revised or replaced with another plan, the process would still function the same way with a different number of digits.
The call processing system includes a process for validating the received telephone number. This process includes at least one of the following: verifying the telephone number is ten digits in length, only contains the numbers 0 through 9, and digits one and four are the numbers 2 through 9 inclusive; comparing the received NPANXX against an Area Code Split File and updating the received NPANXX; indexing the received NPANXX against a Local Exchange Routing Guide (LERG) file and determining the validity of the received NPANXX-XXXX; and comparing the received NPANXX against a VandH coordinate file to determine the type of NPANXX and the location of the NPANXX.
The Master Telephone Number to Spatial Key database is a Virtual Telephone Number database created via Spatial Key linkage. It is created by combining a Master Telephone Number to Spatial Key database with a Spatial Key indexed database. The invention also includes a set of processes to maintain the Master Telephone Number to Spatial Key database: a process for data providers to provide Master Table Verification Records; a process to Build Master Table Update Records from Data Provider Supplied Verification Records; a Master Table Update preprocess; and a Master Table Update process.
The Spatial Key indexed database includes one of the following: Spatial database, Geographic database, USPS Address database, Household database, Individual database linked to a Household database, Business Locations database, Business Financial database linked to a Business Locations database, Government Locations database, Property database, Client Table, or Service Locations Table linked to a Client Table.
The call processing system is designed in a modular manner to support many different clients or advertisers with many different applications. The set of system modules required to satisfy a specific client application is generally only a subset of the total system capabilities. These individual primary modules are summarized below. They include providing a means for:
1. Spatial Key database coding and maintenance.
2. Providing caller communication with a CTI network.
3. Capturing and validating the caller provided telephone number and the vanity number dialed.
4. Linking the captured telephone number to a Spatial Key via a Master Telephone Number to Spatial Key table.
5. Linking the Spatial Key to Spatial Key coded and/or indexed spatial, geographic, USPS address, household, individual, property, business location, government location record databases to retrieve data associated with the caller.
6. Linking the Caller""s Spatial Key to service location ID(s) or telephone number(s) stored in a pre-built and Spatial Key coded and indexed Client Table associated with the vanity number dialed (DNIS).
7. Linking the servicing location ID(s) or telephone number(s) retrieved from the Client Table to other service location specific data stored in a Service Locations table associated with the vanity number dialed and indexed by ID or telephone number.
8. Connecting the caller to an exceptions handling operator or system.
9. Spatially relating, in the form of a map or directions, the caller provided telephone number location with the selected servicing location.
10. Connecting or transferring the caller to a servicing location.
11. Storing selected call information to be accessed later by the caller, the serving location, and/or the vanity advertiser.
12. Providing call, call parallel and/or post call information to the caller relating to the servicing location and/or the spatial relationship between the servicing location and the location of the caller provided telephone number.
13. Providing the caller with a post call communications.
14. Providing call, call parallel and/or post call information to the vanity number advertiser and the servicing location(s) regarding the ANI, DNIS, caller provided telephone number and corresponding Spatial Key, and data retrieved or processed from databases using the Spatial Key as a linkage means.
15. Providing the vanity number advertiser and servicing locations post call communications.
In one aspect of the present invention, there is a method of using an identifier received during communication over a network and at least one publicly available database to link to and retrieve information related to an entity selected from a plurality of entities, wherein the entity is selected via a linkage key determined from the received identifier, the method comprising receiving an identifier during communication over a network; associating the received identifier with a linkage key, wherein the linkage key is based on information obtained at least in part from one of: a United States Postal Service (USPS) National Address database, a USPS ZIP Code database, a USPS City State database, a USPS Delivery Sequence database, a United States Census Bureau Topographically Integrated Geographic Encoding and Referencing system (TIGER) database, a database containing latitude and longitude coordinates for a plurality of street links, a North American Datum (NAD) database, a national Telephone Number Plan Area database, and a national Local Exchange Routing Guide (LERG) database; selecting, via the linkage key, at least one entity from a plurality of entities; retrieving information associated with the at least one selected entity; and providing the retrieved information to the network.
In another aspect of the present invention, there is a method of using an identifier received during communication over a network and at least one publicly available database to link to and retrieve information related to an entity selected from a plurality of entities, wherein the entity is selected via a linkage key determined from the received identifier, the method comprising receiving an identifier during communication over a network; associating the received identifier with a linkage key; selecting, via the linkage key, at least one entity from a plurality of entities; retrieving information associated with the at least one selected entity including information derived at least in part from a publicly available database selected from one of: a United States Postal Service (USPS) National Address database, a USPS ZIP Code database, a USPS City State database, a USPS Delivery Sequence database, a United States Census Bureau Topographically Integrated Geographic Encoding and Referencing system (TIGER) database, a database containing latitude and longitude coordinates for a plurality of street links, a North American Datum (NAD) database, a national Telephone Number Plan Area database, and a national Local Exchange Routing Guide (LERG) database; and providing the retrieved information to the network.
In another aspect of the present invention, there is a method of ordering products or services from an entity selected from a plurality of entities based on an identifier received during communication over a network, the method comprising receiving an identifier during communication over a network; associating the received identifier with a linkage key, wherein the linkage key is based on information obtained at least in part from one of: a United States Postal Service (USPS) National Address database, a USPS ZIP Code database, a USPS City State database, a USPS Delivery Sequence database, a United States Census Bureau Topographically Integrated Geographic Encoding and Referencing system (TIGER) database, a database containing latitude and longitude coordinates for a plurality of street links, a North American Datum (NAD) database, a national Telephone Number Plan Area database, and a national Local Exchange Routing Guide (LERG) database; selecting, via the linkage key, an order-accepting entity from a plurality of entities; retrieving information associated with the selected order-accepting entity; and providing the retrieved information to the network to enable placing an order with the selected order-accepting entity.
These features of the present invention will become more fully apparent from the following description and appended claims taken in conjunction with the accompanying drawings.